home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1992 June: ROMin Holiday / ADC Developer CD (1992-06) (''ROMin Holiday'')_iso / Developer Connection - 06-1992.iso / Development Platforms / Apple II / Essentials / Technical.Notes / IIGS / TN.IIGS.070 < prev    next >
Encoding:
Text File  |  1989-09-03  |  10.7 KB  |  219 lines  |  [TEXT/pdos]
  1. Apple II
  2. Technical Notes
  3. _____________________________________________________________________________
  4.                                                   Developer Technical Support
  5.  
  6.  
  7. Apple IIGS
  8. #70:    Fast Graphics Hints
  9.  
  10. Written by:    Don Marsh & Jim Luther    September 1989
  11.  
  12. This Technical Note discusses techniques for fast animation on the Apple IIGS.
  13. _____________________________________________________________________________
  14.  
  15. QuickDraw II gives programmers a very generalized way to draw something to the 
  16. Super Hi-Res screen or to other parts of Apple IIGS memory.  Unfortunately, 
  17. the overhead in QuickDraw II makes it an unacceptable tool for all but simple 
  18. animations.  If you bypass QuickDraw II, your application has to write pixel 
  19. data directly to the Super Hi-Res graphics display buffer.  It also has to 
  20. control the New-Video register at $C029, and set up the scan-line control 
  21. bytes and color palettes in the graphics display buffer.  Chapter 4 of the 
  22. Apple IIGS Hardware Reference documents where you can find the graphics 
  23. display buffer in memory and how the scan-line control bytes, color palettes, 
  24. and pixel data bytes are used in Super Hi-Res graphics mode.  The techniques 
  25. described in this Note should be used with discretion--we do not recommend 
  26. bypassing the Apple IIGS Toolbox unless it is absolutely necessary.
  27.  
  28. Map the Stack Onto Video Memory
  29.  
  30. To achieve the fastest screen updates possible, you must remove all 
  31. unnecessary overhead from the instructions that perform graphics memory 
  32. writes.  The obvious method for achieving sequential writes to the graphics 
  33. memory uses an index register, which must be incremented or decremented 
  34. between writes.  These operations can be avoided by using the stack.  Each 
  35. time a byte or word is pushed onto the stack, the stack pointer is 
  36. automatically decremented by the appropriate amount.  This is faster than 
  37. doing an indexed store followed by a decrement instruction.
  38.  
  39. But how is the stack mapped onto the graphics memory?  The stack can be 
  40. located in bank $01 instead of bank $00 by writing to the WrCardRAM auxiliary-
  41. memory select switch at $C005.  Bank $01 is shadowed into $E1 by clearing bit 
  42. 3 of the Shadow register at $C035.  Under these conditions, if the stack 
  43. pointer is set to $3000, the next byte pushed onto the stack is written to 
  44. $013000, then shadowed into $E13000.  The stack pointer is automatically 
  45. decremented so the stage is set for another byte to be written at $E12FFF.
  46.  
  47. Warning:  While the stack is mapped into bank $01, you may not call 
  48.           any firmware, toolbox or operating system routines (ProDOS 
  49.           8 or GS/OS).  Don't even think about it.
  50.  
  51. Unroll All Loops
  52.  
  53. Another source of overhead is branching instructions in loops.  By "straight-
  54. lining" the code to move up a scan-line's worth of memory at one time, branch 
  55. instructions are avoided.  Following is an example of this technique.
  56.  
  57.  
  58.     lda    |164,y            ; accumulator is 16 bits for
  59.     pha                      ; best efficiency
  60.     lda    |162,y
  61.     pha
  62.     lda    |160,y
  63.     pha
  64.  
  65. In this example, the Y register is used to point to data to be moved to the 
  66. graphics memory, and hard-coded offsets from the Y register are used to avoid 
  67. register operations between writes.
  68.  
  69. Hard-Code Instructions and Data
  70.  
  71. In desperate circumstances, it is necessary to remove overhead from the 
  72. previous code example.  This can be accomplished by hard-coding pixel data 
  73. into your code instead of loading pixel values from a separate data space and 
  74. transferring them to the graphics memory (as in the example).  If you are 
  75. writing an arbitrary pattern of three or fewer constant values to the screen, 
  76. for example, the following method is the fastest known:
  77.  
  78.     lda    #val1
  79.     ldx    #val2
  80.     ldy    #val3
  81.     pha                      ; arbitrary pattern of pushes
  82.     phx
  83.     phy
  84.     phy
  85.     phx
  86.  
  87. In cases where many different values must be written to the screen, pixel data 
  88. can be written to the screen using immediate push instructions:
  89.  
  90.     pea    $5389             ; some arbitrary pixel values
  91.     pea    $2378
  92.     pea    $A3C1
  93.     pea    $39AF
  94.  
  95. Your program can generate this mixture of PEA instructions and pixel data 
  96. itself, or it could load pixel data that already has PEA instructions 
  97. intermixed (thus increasing the data size by one half).
  98.  
  99. Be Aware of Slow-Side and Fast-Side Synchronization
  100.  
  101. Estimating execution speed by counting instruction cycles is always a 
  102. challenging task on the IIGS, but it is particularly tricky when one is 
  103. writing to the graphics memory.  The graphics memory resides in the side of 
  104. the IIGS system controlled by the 1 MHz Mega II chip, which means that during 
  105. all writes to this memory, the fast side of the system controlled by the Fast 
  106. Processor Interface (FPI) chip must be synchronized with slow side of the 
  107. system controlled by the Mega II, even if the system is running code at full 
  108. native speed.  This synchronization is performed automatically and 
  109. transparently by the FPI in the IIGS, and it isn't normally of concern to the 
  110. programmer.  Animation programmers must worry about synchronization delays, 
  111. however, because slight changes in graphics update code may change the 
  112. frequency of these delays, and hence the speed of the program.  In practical 
  113. terms, this means that one loop writing data to the graphics memory may run at 
  114. the same speed as a second loop with a higher cycle count.
  115.  
  116. A careful analysis of the synchronization problem leads to the following 
  117. tables, which are useful as a rough estimate of the speed attained by 
  118. different pieces of code.  Each entry is based on the number of cycles 
  119. consumed during consecutive write instructions.  For example, a series of PEA 
  120. instructions requires five cycles for each 16-bit write.  A short PHA 
  121. instruction followed by a branch requires six cycles for each 8-bit write.
  122.  
  123.     Fast Cycles per Write (byte)    Actual Speed (microseconds/byte)
  124.     ________________________________________________________________
  125.               3 to 5                           2.0
  126.               6 to 8                           3.0
  127.               9 to 11                          4.0
  128.     ________________________________________________________________
  129.  
  130.     Fast Cycles per Write (word)    Actual Speed (microseconds/word)
  131.     ________________________________________________________________
  132.               4 to 6                           3.0
  133.               7 to 8                           4.0
  134.               9 to 11                          5.0
  135.     ________________________________________________________________
  136.  
  137. The times given in the tables apply only if the same number of fast cycles 
  138. separate each consecutive write operation.  The first write operation in a set 
  139. of write instructions usually takes longer than subsequent writes, because the 
  140. potentially long synchronization operation is accomplished at that time.  
  141. Unpredictable delays caused by memory refresh slow things down further, 
  142. although refresh delays byte-wide writes more often than word-wide writes.  
  143. Therefore, it is usually preferable from a speed standpoint to use word-wide 
  144. writes to the graphics memory.
  145.  
  146. For more information on synchronization cycle timing within the IIGS, see 
  147. Chapter 2 of the Apple IIGS Hardware Reference and Apple IIGS Technical Note 
  148. #68, Tips for I/O Expansion Slot Card Design.
  149.  
  150. Use Change Lists
  151.  
  152. The timing data given in the preceding section shows that it is not possible 
  153. to perform full-screen updates in the time it takes the IIGS to scan the 
  154. entire screen.  In fact, it would be difficult to update more than one-sixth 
  155. of the screen in one scan time. Therefore, it is necessary to update only 
  156. those pixels which have actually changed from the previous frame of animation.  
  157. One method of doing this is to precalculate the pixels which change by 
  158. comparing each frame against the preceding frame.  For interactive animation, 
  159. fast methods must be developed for predicting which areas of the screen must 
  160. be updated (a determination of the exact pixels might require more computation 
  161. than the actual update would require).
  162.  
  163. Using the Video Counters
  164.  
  165. To achieve "tear-free" screen updates, it is necessary to monitor the location 
  166. of the scan-line beam when writing to graphics memory.  As described in Apple 
  167. IIGS Technical Note #39, Mega II Video Counters, the VertCnt and HorizCnt Mega 
  168. II video counter registers at $C02E-C02F allow you to determine which scan 
  169. line is currently being drawn.
  170.  
  171. By using only the VertCnt register and ignoring the low bit of the 9-bit 
  172. vertical counter stored in HorizCnt, you can determine within 2 scan lines 
  173. which scan line is currently being drawn.  The VertCnt video counter contains 
  174. the number of the current scan line divided by two, offset by $80.  For 
  175. example, if the scan-line beam was currently refreshing either scan line four 
  176. or five, VertCnt would contain $82 (4/2 + $80 or 5/2 + $80).  Vertical 
  177. blanking happens during VertCnt values $7D through $7F and $E4 through $FF.
  178.  
  179. Clever updates can modify twice as many pixels on the screen by sacrificing 
  180. some smoothness, running at 30 frames per second instead of 60.  The technique 
  181. is as follows:
  182.  
  183.   1.  Wait for the scan line beam to reach the first scan line.
  184.   2.  Start updates from the top of the screen, being careful not to 
  185.       pass the scan line beam.
  186.   3.  Continue updates while the scan line beam progresses toward the 
  187.       bottom of the screen, then goes into vertical blanking, then 
  188.       restarts at the top of the screen.
  189.   4.  Finish the update before the scan line beam catches the update 
  190.       point.
  191.  
  192. Careful use of this method allows a frame to be updated during two scans of 
  193. the screen instead of just one.  If you are not sufficiently careful, tearing 
  194. results.
  195.  
  196. Note:  The Apple IIGS main logic board Mega II-VGC registers and 
  197.        interrupts are not synchronous to the Apple II Video Overlay Card 
  198.        video and therefore should not be used for time synchronization 
  199.        with the Apple II Video Overlay Card video output. However, they 
  200.        can be used for time synchronization with the Apple IIGS video 
  201.        output.  See the Apple II Video Overlay Card Development Kit for 
  202.        more information.
  203.  
  204. Interrupts
  205.  
  206. It is not possible to support interrupts while sustaining a high graphics 
  207. update rate, unless jerkiness or tearing is acceptable.  Be aware that many 
  208. system activities such as GS/OS and AppleTalk depend on interrupts and do not 
  209. function if interrupts are disabled.
  210.  
  211.  
  212. Further Reference
  213. _____________________________________________________________________________
  214.   o  Apple IIGS Firmware Reference
  215.   o  Apple IIGS Hardware Reference
  216.   o  Apple II Video Overlay Card Development Kit 
  217.   o  Apple IIGS Technical Note #39, Mega II Video Counters
  218.   o  Apple IIGS Technical Note #40, VBL Signal
  219.   o  Apple IIGS Technical Note #68, Tips for I/O Expansion Slot Card Design